Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

platform/DRMFormat: Don't require a FormatInfo for each format. #3463

Merged
merged 7 commits into from
Jul 15, 2024

Conversation

RAOF
Copy link
Contributor

@RAOF RAOF commented Jul 5, 2024

We're now using DRMFormat in a situation (linux-dmabuf) where:

  • We don't actually need to care about many the properties of the format, and
  • We're processing formats submitted by cilents.

This means that the existing “throw an exception if we haven't got a FormatInfo” approach works badly; we will disconnect clients with a Wayland internal error if they submit buffers in a format we haven't explicitly listed, even though it would work if we just treated the format as an opaque identifier.

So, don't do that anymore. Instead, store the fourcc code directly in DRMFormat, only look up the FormatInfo (now DRMFormat::Info) when code asks for it.

Additionally, we log the first time code asks for the DRMFormat::Info for a format we haven't got info for; this way we can fill out the needed formats on an as-noticed basis.

Fixes: #3462

We're now using `DRMFormat` in a situation (linux-dmabuf) where:
* We don't actually need to care about many the properties of the format, and
* We're processing formats submitted by cilents.

This means that the existing “throw an exception if we haven't got a `FormatInfo`”
approach works badly; we will disconnect clients with a Wayland internal error
if they submit buffers in a format we haven't explicitly listed, even though it
*would* work if we just treated the format as an opaque identifier.

So, don't do that anymore. Instead, store the fourcc code directly in `DRMFormat`
alongside the `FormatInfo` if it exists.

Fixes: #3462
@RAOF RAOF requested a review from a team as a code owner July 5, 2024 04:34
Copy link

codecov bot commented Jul 5, 2024

Codecov Report

Attention: Patch coverage is 30.23256% with 30 lines in your changes missing coverage. Please review.

Project coverage is 76.97%. Comparing base (eec03e0) to head (2d01c22).
Report is 409 commits behind head on main.

Files with missing lines Patch % Lines
src/platform/graphics/drm_formats.cpp 39.13% 14 Missing ⚠️
src/platforms/gbm-kms/server/buffer_allocator.cpp 0.00% 13 Missing ⚠️
src/platform/graphics/linux_dmabuf.cpp 0.00% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3463      +/-   ##
==========================================
- Coverage   77.36%   76.97%   -0.39%     
==========================================
  Files        1076     1081       +5     
  Lines       68911    69384     +473     
==========================================
+ Hits        53310    53407      +97     
- Misses      15601    15977     +376     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@RAOF
Copy link
Contributor Author

RAOF commented Jul 5, 2024

I'm not sure if I like this; particularly because we now don't have any signal for “it would be useful to have information on this format, but we don't have it”.

It might be better to separate DRMFormat and DRMFormat::FormatDetails, and have the latter be an optional<> that may contain the current details. Then, only code that cares about the details can try to access them, and we can error (or, at least, log a warning/error) if those details are unavailable.

This way things which treat `DRMFormat` as entirely opaque don't pay for the extra
format information, and we can warn when the things that *do* care about the format
details try to look up details we haven't included yet.
@RAOF
Copy link
Contributor Author

RAOF commented Jul 8, 2024

It might be better to separate DRMFormat and DRMFormat::FormatDetails, and have the latter be an optional<> that may contain the current details. Then, only code that cares about the details can try to access them, and we can error (or, at least, log a warning/error) if those details are unavailable.

I have now Done This.

Copy link
Contributor

@mattkae mattkae left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A minor thing about symbols, but this makes sense to me overall

src/platform/symbols.map Show resolved Hide resolved
Copy link
Contributor

@mattkae mattkae left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A single question that I might be wrong on, but looks good to me 😄

src/platform/symbols.map Show resolved Hide resolved
Copy link
Collaborator

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks mostly sensible. But we can do better with reporting missing format info

Comment on lines 485 to 489
/* TODO: This could fire quite frequently.
* Ideally we would have a rate-limited (or once-per-format) logger, but for now, just
* throw it in the debug stream.
*/
mir::log_debug("Detailed info for format %s missing; please report so this can be added", name());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot of TODOs being added. In linux_dmabuf.cpp we say something similar, but in that context we don't log. I think we need a better approach to reporting this. BTW "rate-limiting" doesn't sound right either.

With this approach, I think "debug" logging requesting reporting is addressing the wrong audience. "debug" and "trace" are for those familiar with the code. "Warning" might be better.

* throw it in the debug stream.
*/
mir::log_debug("Detailed info for format %s missing; please report so this can be added", name());
return {};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

std::nullopt?

@RAOF
Copy link
Contributor Author

RAOF commented Jul 12, 2024

There we go! I have JFDI and resolved the TODOs rather than adding them.

Copy link
Collaborator

@AlanGriffiths AlanGriffiths left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some nitpicking. Feel free to land anyway

Comment on lines 491 to 494
if (!unknown_formats->contains(fourcc))
{
mir::log_warning("Detailed info for format %s missing; please report so this can be added", name());
unknown_formats->insert(fourcc);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is a micro optimisation but...

Suggested change
if (!unknown_formats->contains(fourcc))
{
mir::log_warning("Detailed info for format %s missing; please report so this can be added", name());
unknown_formats->insert(fourcc);
if (unknown_formats->insert(fourcc).second)
{
mir::log_warning("Detailed info for format %s missing; please report so this can be added", name());

Also, maybe some guidance on where to report?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've put a link to GitHub issues in the message text. I haven't taken the micro-optimisation, because I think it makes the intent slightly less obvious and it is the micro-est of micro-optimisations.

@RAOF RAOF enabled auto-merge July 15, 2024 05:32
@RAOF RAOF added this pull request to the merge queue Jul 15, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jul 15, 2024
@RAOF RAOF added this pull request to the merge queue Jul 15, 2024
Merged via the queue into main with commit 538f6b0 Jul 15, 2024
34 of 36 checks passed
@RAOF RAOF deleted the dont-die-on-unknown-drm-formats branch July 15, 2024 11:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Nautilus open-with dialog crashes with Mir internal error (Missing DRM_FORMAT_ABGR16161616F)
3 participants